Application identity-based enforcement of datagram protocols

ABSTRACT

Systems and methods include obtaining telemetry from a plurality of security agents each operating on a device in a network, wherein the telemetry is collected locally related to datagram protocol packets; analyzing the telemetry to determine applications associated with the datagram protocol packets flowing in the network and virtual circuits between each of the applications; determining enforcement policies for each application that communicates with other applications over a datagram protocol; and providing the enforcement policies to the plurality of security agents for allowing and blocking communications associated with the datagram protocol.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to networking and computing.More particularly, the present disclosure relates to systems and methodsfor application identity-based enforcement of datagram protocols.

BACKGROUND OF THE DISCLOSURE

Flat networks increase risk in the cloud and data centers. A flatnetwork is one where various hosts are interconnected in a network withlarge segments. Flat networks allow excessive access via unprotectedpathways that allow attackers to move laterally and compromise workloadsin cloud and data center environments. Experts agree that shrinkingsegments and eliminating unnecessary pathways is a core protectionstrategy for workloads. However, the cost, complexity, and time involvedin network segmentation using legacy virtual firewalls outweighs thesecurity benefit. The best-known approaches to network security requirethat each host on a network and each application have the least possibleaccess to other hosts and applications, consistent with performing theirtasks. In practice, this typically requires creating large numbers ofvery fine-grained rules that divide a network into many separatesubnetworks, each with its own authority and accessibility. This isreferred to as “segmentation” (or referred to as “microsegmentation,”which is described herein and the differences with segmentation) and isa key aspect of so-called Zero Trust Network Access (ZTNA). Shrinkingnetwork segments advantageously eliminates unnecessary attack paths andreduces the risk of compromises. Workload segmentation advantageouslystops the lateral movement of threats and prevents applicationcompromises and data breaches. ZTNA, also known as the Software-DefinedPerimeter (SDP), is a set of technologies that operates on an adaptivetrust model, where trust is never implicit, and access is granted on a“need-to-know,” least-privileged basis defined by granular policies.

In practice, it is very difficult to perform segmentation well. Knowingin detail what functions a network is performing and then craftinghundreds or thousands of precise rules for controlling access within thenetwork is a process that often takes years and is prone to failure.Crafting such rules is difficult and expensive to perform manuallyprecisely because it requires humans to perform several tasks thathumans find it difficult to perform well, such as understanding big dataand writing large sets of interacting rules. Legacy network security iscomplex and time-consuming to deploy and manage. Address-based,perimeter controls, such as via firewalls, were not designed to protectinternal workload communications. As a result, attackers can “piggyback”on approved firewall rules. Application interactions have complexinterdependencies. Existing solutions translate “application speak” to“network speak,” resulting in thousands of policies that are almostimpossible to validate. Stakeholders need to be convinced that the riskwill be reduced. Can security risk be reduced without breaking theapplication? Practitioners struggle to measure the operational risk ofdeploying complex policies accurately.

While all agree segmentation reduces risk, there is uncertainty inpractice that it can be applied effectively. There are techniquesdescribed for implementing automated microsegmentation, such as, forexample, described in U.S. patent application Ser. No. 17/101,383, filedNov. 23, 2020, and entitled “Automatic segment naming inMicrosegmentation,” and U.S. Pat. No. 10,154,067, issued Dec. 11, 2018,and entitled “Network Application Security Policy Enforcement,” thecontents of each are incorporated by reference herein.

Zero-Trust identity-based protection of datagram-based protocols (e.g.,User Datagram Protocol (UDP)) have various challenges to deliver anenforcement solution. First, there is a need to be able to identifywhich applications are communicating with each other over a datagramprotocol. Second, a zero-trust system must determine which applicationsare capable of responding to unsolicited datagram protocol messages—asthese applications must be treated differently by the zero-trust policygeneration system. Third, the system must limit the amount of telemetryit calculates and sends, while still providing a high degree ofcertainty that all pairs of communicating software will be: 1) promptlydetected, 2) correctly enforced, and 3) accurately recorded in a durableaudit trail.

BRIEF SUMMARY OF THE DISCLOSURE

The present disclosure relates to systems and methods for applicationidentity-based enforcement of datagram protocols. The goal ofmicrosegmentation is to limit host and application access as much aspossible in a Zero Trust architecture. Systems and methods includeobtaining telemetry from a plurality of security agents each operatingon a device in a network, wherein the telemetry is collected locallyrelated to datagram protocol packets; analyzing the telemetry todetermine applications associated with the datagram protocol packetsflowing in the network and virtual circuits between each of theapplications; determining enforcement policies for each application thatcommunicates with other applications over a datagram protocol; andproviding the enforcement policies to the plurality of security agentsfor allowing and blocking communications associated with the datagramprotocol.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated and described herein withreference to the various drawings, in which like reference numbers areused to denote like system components/method steps, as appropriate, andin which:

FIG. 1 is a network diagram of a network illustrating conventionalmicrosegmentation.

FIG. 2 is a network diagram of the network illustrating automatedmicrosegmentation.

FIG. 3 is a network diagram of a system for generating networkapplication security policies.

FIG. 4 is a flowchart of an automated microsegmentation process.

FIG. 5 is a network diagram of a cloud-based system offering security asa service.

FIG. 6 is a block diagram of a server.

FIG. 7 is a block diagram of two systems communicating to one anotherand their example cryptographic identities, i.e., fingerprints.

FIG. 8 is a flowchart of an automated microsegmentation and segmentnaming process.

FIG. 9 is a flowchart of an auto segmentation process for automaticallyproposing network microsegments and for, optionally, receiving humanapproval of those proposed microsegments.

FIG. 10 is a flowchart of a process for auto re-segmentation to assignnew applications.

FIG. 11 is a flowchart of a process for application identity-basedenforcement of datagram protocols.

DETAILED DESCRIPTION OF THE DISCLOSURE

Again, the present disclosure relates to systems and methods forapplication identity-based enforcement of datagram protocols. The goalof microsegmentation is to limit host and application access as much aspossible in a Zero Trust architecture.

Microsegmentation

Workload segmentation includes an approach to segment applicationworkloads. In an automated manner, with one click, the workloadsegmentation determines risk and applies identity-based protection toworkloads—without any changes to the network. The softwareidentity-based technology provides gap-free protection with policiesthat automatically adapt to environmental changes.

Microsegmentation originated as a way to moderate traffic betweenservers in the same network segment. It has evolved to includeintra-segment traffic so that Server A can talk to Server B orApplication A can communicate with Host B, and so on, as long as theidentity of the requesting resource (server/application/host/user)matches the permission configured for that resource. Policies andpermissions for microsegmentation can be based on resource identity,making it independent from the underlying infrastructure, unlike networksegmentation, which relies on network addresses. This makesmicrosegmentation an ideal technique for creating intelligent groupingsof workloads based on the characteristics of the workloads communicatinginside the data center. Microsegmentation, a fundamental part of theZero Trust Network Access (ZTNA) framework, is not reliant ondynamically changing networks or the business or technical requirementsplaced on them, so it is both stronger and more reliable security. It isalso far simpler to manage—a segment can be protected with just a fewidentity-based policies instead of hundreds of address-based rules.

FIG. 1 is a network diagram of a network 10 illustrating conventionalmicrosegmentation. The network 10 includes hosts 12, databases 14, andfirewalls 16. Legacy network-based microsegmentation solutions rely onthe firewalls 16, which use network addresses for enforcing rules. Thisreliance on network addresses is problematic because networks constantlychange, which means policies must be continually updated as applicationsand devices move. The constant updates are a challenge in a data center,and even more so in the cloud and where Internet Protocols (IP)addresses are ephemeral. Network address-based approaches forsegmentation cannot identify what is communicating—for example, thesoftware's identity—they can only tell how it is communicating, such asthe IP address, port, or protocol from which the “request” originated.As long as they are deemed “safe,” communications are allowed, eventhough IT does not know exactly what is trying to communicate.Furthermore, once an entity is inside a network zone, the entity istrusted. But this trust model can lead to breaches, and that is onemajor reason microsegmentation evolved.

FIG. 2 is a network diagram of the network 10 illustrating automatedmicrosegmentation. Microsegmentation is a way to create secure zones sothat companies can isolate workloads from one another and secure themindividually. It is designed to enable granular partitioning of trafficto provide greater attack resistance. With microsegmentation, IT teamscan tailor security settings to different traffic types, creatingpolicies that limit network and application flows between workloads tothose that are explicitly permitted. In this zero trust security model,a company could set up a policy, for example, that states medicaldevices can only talk to other medical devices. And if a device orworkload moves, the security policies and attributes move with it. Byapplying segmentation rules down to the workload or application, IT canreduce the risk of an attacker moving from one compromised workload orapplication to another.

Microsegmentation is not the same as network segmentation. It is fairlycommon for network segmentation and microsegmentation to be usedinterchangeably. In reality, they are completely different concepts.Network segmentation is best used for north-south traffic, meaning thetraffic that moves into and out of the network. With networksegmentation, an entity, such as a user, is generally considered trustedonce inside a network's designated zone. Microsegmentation is best usedfor east-west traffic, or traffic that moves across the data centernetwork—server-to-server, application-to-server, etc. Simply put,network segmentation is the castle's outer walls, whilemicrosegmentation represents the guards standing at each of the castle'sdoors.

Microsegmentation's main purpose is to reduce the network attack surfaceby limiting east-west communication by applying granular securitycontrols at the workload level. In the simplest terms, the differencesbetween microsegmentation and network segmentation can be boiled downto:

Segmentation Microsegmentation Coarse policies Granular policiesPhysical network Virtual or overlay network North-south trafficEast-west traffic Address based/network level Identity-based/workloadlevel Hardware Software

Since policies and permissions for microsegmentation are based onresource identity (versus a user's/person's identity), it is independentof the underlying infrastructure, which means: Fewer policies to manage,centralized policy management across networks, policies thatautomatically adapt regardless of infrastructure changes, and gap-freeprotection across cloud, container, and on-premises data centers.

Generally, microsegmentation creates intelligent groupings of workloadsbased on characteristics of the workloads communicating inside the datacenter. As such, microsegmentation is not reliant on dynamicallychanging networks or the business or technical requirements placed onthem, which means that it is both stronger and more reliable security.

Network Communication Model

Automated microsegmentation is provided by generating a networkcommunication model by applying machine learning to existing networkcommunications. The resulting model can validate communication betweenapplications (or services) over a network and create network segments.The term “application,” as used herein, includes both applications andservices. Therefore, any reference herein to an “application” should beunderstood to refer to an application or a service.

FIG. 3 is a network diagram of a system 50 for generating networkapplication security policies. The system 50 includes a cloud-basedsystem 100 configured to collect information about which applicationscommunicate with each other in the system 50. The system 50 can bereferred to as a microsegmentation system. An example of the system 50is the Zscaler Workload Segmentation (ZWS) system available fromZscaler, Inc., the applicant of the present disclosure. Such informationincludes, for example, identifying information about each suchapplication (such as its name, the machine on which it executes, itsnetwork address, and the port on which it communicates). The system 50can apply machine learning to such gathered information to create amodel 104 based on the collected network communication information. Themodel 104 is generated to have at least two properties, which can be atleast in part in conflict with each other: (1) accurately reflectexisting network communications, and (2) be in the form ofhuman-readable rules. The model 104 can have each such property to agreater or lesser extent.

As will be described in more detail below, the system 50 can generatethe model 104 even in the absence of training data in which particularnetwork communications are labeled as “healthy” (i.e., desired to bepermitted) or “unhealthy” (i.e., desired to be blocked). One benefit isthat they may generate the model 104 in the absence of such trainingdata, while striking a balance between being permissive enough to permithealthy but previously unseen network communications (e.g., networkcommunications that have properties different than the communicationsthat were used to generate the model 104) and being restrictive enoughto block previously-unseen and unhealthy network communications.

The system 50 can include any number of individual systems from whichthe system 50 may collect network communication information. For ease ofillustration and explanation, only two systems, a source system 102 aand a destination system 102 b, are shown in FIG. 3 . In practice,however, the system 50 may include hundreds, thousands, or more suchsystems, from which the system 50 may collect network communicationinformation using the techniques disclosed herein. A “system,” as thatterm is used herein (e.g., the source system 102 a and/or destinationsystem 102 b), may be any device and/or software application that isaddressable over an Internet Protocol (IP) network. For example, each ofthe source system 102 a and the destination system 102 b can be any typeof computing device, such as a server computer, desktop computer, laptopcomputer, tablet computer, smartphone, or wearable computer. The sourcesystem 102 a and the destination system 102 b can have the same ordifferent characteristics. For example, the source system 102 a can be asmartphone, and the destination system 102 b may be a server computer. Asystem (such as the source system 102 a and/or destination system 102 b)can include one or more other systems and/or be included within anothersystem. As merely one example, a system can include a plurality ofvirtual machines, one of which may include the source system 102 aand/or destination system 102 b. A “host,” as that term is used herein,is an example of a system.

The source system 102 a and destination system 102 b are labeled as suchin FIG. 3 merely illustrates a use case in which the source system 102 ainitiates communication with the destination system 102 b. In practice,the source system 102 a can initiate one communication with thedestination 102 b and thereby act as the source for that communication,and the destination system 102 b can initiate another communication withthe source system 102 a and thereby act as the source for thatcommunication. As these examples illustrate, each of the source system102 a and the destination system 102 b may engage in multiplecommunications with each other and with other systems within the system50 and can act as either the source or destination in thosecommunications. The system 50 may use the techniques disclosed herein tocollect network communication information from any or all such systems.

The source system 102 a includes a source application 104 a, and thedestination system 102 b includes a destination application 104 b. Eachof these applications 104 a and 104 b can be any kind of application, asthat term is used herein. The source application 104 a and thedestination application 104 b can have the same or differentcharacteristics. For example, the source application 104 a anddestination application 104 b can both be the same type of applicationor even be instances of the same application. As another example, thesource application 104 a can be a client application, and thedestination application 104 b can be a server application or vice versa.

Before describing the system 50 in more detail, certain terms will bedefined. The system 50 can collect information about applications thatcommunicate with each other over a network within the system 50. Thesystem 50 may, for example, collect such network communicationinformation using a network information collection agent executing oneach of one or more systems within the system 50. For example, in FIG. 3, source system 102 a includes a network information collection agent106 a and destination system 102 b includes a network informationcollection agent 106 b. The agents 106 a-b can perform any of thefunctions disclosed herein for collecting network communicationinformation. The agents 106 a-b can also be referred to as localsecurity agents, network information collection agents, a combination oflocal security agents and network information collection agent, orsimply agents. The functionality of the agents 106 a-b is to performdata collection and policy enforcement for the various microsegmentationtechniques described herein.

For example, the network information collection agent 106 a on thesource system 102 a can collect, for each network communication (e.g.,connection request, message, packet) transmitted or received by thesource system 102 a, any one or more of the following units ofinformation:

the local IP address and port of the communication the remote IP addressand port of the communication the host (machine) name of the system onwhich the agent 106a is executing (e.g., the source system 102a) aunique identifier of the agent 106a (also referred to herein as a“source agent ID” or “local agent ID”) an identifier (e.g., name) of theapplication transmitting or receiving the communication on the system onwhich the agent 106a is executing (also referred to herein as a “sourceapplication ID” or “local application ID”) a unique identifier of theagent 106b (also referred to herein as a “destination agent ID” or“remote agent ID”) an identifier (e.g., name) of the applicationtransmitting or receiving the communication on the system on which theagent 106b is executing (also referred to herein as a “destinationapplication ID” or “remote application ID”) an identifier (e.g.,username) of the user executing the application on the system on whichthe agent 106a is executing an identifier (e.g., username) of the userexecuting the application on the system on which the agent 106b isexecuting

Information about the agents 106 a-b described above can be used asagent “fingerprints.” For example, an agent fingerprint for the agent106 a can include any one or more of the following: the agent 106 a's IPaddress, the hostname of the system 102 a on which the agent 106 a isexecuting, and the name and version of the operating system executing onthat system. Similarly, an application fingerprint may, withoutlimitation, include any one or more of the following: the name of theapplication, a full pathname to the binary file of the application; ahash of that binary file which (almost certainly) uniquely identifiesthe binary file; and a Locality-Sensitive Hash (LSH) of the binary file.The present disclosure can generate, store, read, and write fingerprintsfor any of the agents and applications disclosed herein.

The network information collection agent 106 a on the source system 102a can transmit a message 112 a to a cloud-based system 100, containingsome or all of the information collected above and/or informationderived therefrom. The network information collection agent 106 a cancollect such information for any number of communications (e.g., atleast one million, one hundred million, one billion, one hundredbillion, or one trillion communications) transmitted and/or received byone or more applications (e.g., source application 108 a) executing onthe source system 102 a, and transmit any number of instances of message112 a (e.g., at least one million, one hundred million, one billion, onehundred billion, or one hundred billion instances of message 112 a)containing such collected information to the cloud-based system 100 overtime (e.g., periodically). In other words, the system 50 can repeatoperations for any number of communications at the source system 102 aover time to collect and transmit network communication information forsuch communications.

The description above of the functions performed by the networkinformation collection agent 106 a on the source system 102 a applyequally to a network information collection agent 106 b on thedestination system 102 b, which can collect network communicationinformation for any number of communications (e.g., at least onemillion, one hundred million, one billion, one hundred billion, or onetrillion communications) transmitted and/or received by one or moreapplications (e.g., destination application 108 b) executing on thedestination system 102 b using any of the techniques disclosed herein,and transmit any number of instances of message 112 b (e.g., at leastone million, one hundred million, one billion, one hundred billion, orone trillion instances of message 112 a) containing such collectedinformation to the cloud-based system 100 over time (e.g.,periodically).

As the system 50 gathers network communication information (e.g., byusing the network information collection agents 106 a-b in the mannerdisclosed above), the system 50 can store the gathered information. Theset of information that the system 50 collects in connection with aparticular executing application is referred to herein as a “flow.” Anyparticular application flow may contain information collected from oneor more communications transmitted and/or received by that application.The system 50 can combine multiple sequential flows between anapplication X and an application Y into a single flow (possiblyassociated with duration). However, communication between application Xand another application Z will be in a separate flow, and flows betweenX and Z, if there is more than one, will be combined separately fromflows between X and Y. An example of a flow that may be generated as theresult of collecting network communication information for a particularapplication (e.g., source application 108 a) is the following: (1)timestamp: 1481364002.234234; (2) id: 353530941; (3) local_address:149.125.48.120; (4) local_port: 64592; (5) lclass: private; (6)remote_address: 149.125.48.139; (7) remote_port: 62968; (8) rclass:private; (9) hostId: 144; (10) user: USER1; (11) exe:/usr/bin/java; (12)name: java; (13) cmdlineId: 9; (14) duration: 0.0.

As the network information collection agent 106 a on the source system102 a gathers network communication information from networkcommunications sent and received by applications executing on the sourcesystem 102 a (e.g., source application 108 a), the network informationcollection agent 106 a can store such information in the form of flowdata 114 a on the source system 102 a. The flow data 114 a can includedata representing a flow for each of one or more applications executingon the source system 102 a. For example, the flow data 114 a can includeflow data representing a flow for the source application 108 a, wherethe network information collection agent generated that flow data basedon network communication information collected from networkcommunications transmitted and/or received by the source application 108a. Instances of the message 112 a transmitted by the network informationcollection agent 106 a to the remote server 110 can include some or allof the flow data 114 a and/or data derived therefrom.

Similarly, the network information collection agent 106 b on thedestination system 102 b can generate flow data 114 b representing aflow for each of one or more applications executing on the destinationsystem 102 b (e.g., destination application 108 b), using any of thetechniques disclosed herein in connection with the generation of theflow data 114 a by the network information collection agent 106 a.Instances of the message 112 b transmitted by the network informationcollection agent 106 b to the cloud-based system 100 may include some orall of the flow data 114 b and/or data derived therefrom.

The term “flow object,” as used herein, refers to a subset of flow datathat corresponds to a particular application. For example, one or moreflow objects within the flow data 114 a can correspond to the sourceapplication 108 a, and one or more flow objects within the flow data 114b may correspond to the destination application 108 b. A flow objectwhich corresponds to a particular application may, for example, containdata specifying that the source application 108 a is the sourceapplication of the flow represented by the flow object. As anotherexample, a flow object which corresponds to a particular applicationmay, for example, contain data specifying that the destinationapplication 108 b is the destination application of the flow representedby the flow object.

Now consider a flow object within the flow data 114 a, corresponding tothe source application 108 a. Assume that this flow object representsthe source application 108 a's side of communications between the sourceapplication 108 a and the destination application 108 b. There is,therefore, also a flow object within the flow data 114 b, correspondingto the destination application 108 b's side of the communicationsbetween the source application 108 a and the destination application 108b. Assume that the network information collection agent 106 a on thesource system 102 a transmits messages 112 a containing the flow objectrepresenting the source application 108 a's side of its communicationswith the destination application 108 b and that the network informationcollection agent 106 b on the destination system 102 b transmitsmessages 112 b contain the flow object representing the destinationapplication 108 b's side of its communications with the sourceapplication 108 a. As a result, the cloud-based system 100 receives andcan store information about both the flow object corresponding to thesource application 108 a and the flow object corresponding to thedestination application 108 b.

These two flow objects, which correspond to the two ends of anapplication-to-application communication (i.e., between the sourceapplication 108 a and the destination application 108 b), can match upor correlate with each other in a variety of ways. For example, thelocal IP address and port of the flow object corresponding to the sourceapplication 108 a is the same as the remote IP address and port,respectively, of the flow object corresponding to the destinationapplication 108 b, and vice versa. In other words, the flow objectcorresponding to the source application 108 a can contain dataspecifying a particular remote IP address and port, and the flow objectcorresponding to the destination application 108 b can contain dataspecifying the same remote IP address and port as the flow objectcorresponding to the source application 108 a. Various other data withinthese two flow objects may match up with each other as well.

A matching module 116 in the cloud-based system 100 can identify flowobjects that correspond to the two ends of an application-to-applicationcommunication and then combine some or all of the data from the two flowobjects into a combined data structure that is referred to herein as a“match object,” which represents what is referred to herein as a“match.” A “match,” in other words, represents the two correspondingflows at opposite (i.e., source and destination) ends of anapplication-to-application communication.

More generally, the matching module 116 can receive collected networkinformation from a variety of systems within the system 50, such as byreceiving network information messages 112 a from the source system 102a and network information messages 112 b from the destination system 102b. As described above, these messages 112 a-b can contain flow datarepresenting information about flows in the source system 102 a anddestination system 102 b, respectively. The matching module 116 can thenanalyze the received flow data to identify pairs of flow objects thatrepresent opposite ends of application-to-application communications.For each such identified pair of flow objects, the matching module 116can generate a match object representing the match corresponding to thepair of flow objects. Such a match object may, for example, contain thecombined data from the pair of flow objects.

The matching module 116 can impose one or more additional constraints onpairs of flow objects in order to conclude that those flow objectsrepresent a match. For example, the matching module 116 can require thatthe transmission time of a source flow object (e.g., in the source flowdata 114 a) and the receipt time of a destination flow object (e.g., inthe destination flow data 114 b) differ from each other by no more thansome maximum amount of time (e.g., 1 second) in order to consider thosetwo flow objects to represent a match. If the difference in time is lessthan the maximum permitted amount of time, then the matching module 116may treat the two flow objects as representing a match; otherwise, thematching module 116 may not treat the two flow objects as representing amatch, even if they otherwise satisfy the criteria for a match (e.g.,matching IP addresses).

The system 50 also includes a network communication model generator 120,which receives the match data 118 as input and generates the networkcommunication model 104 based on the match data 118. Because the matchesrepresent flows, which in turn represent actual communications withinthe network, the network communication model generator 120 generates thenetwork communication model 104 based on actual communications withinthe network.

As mentioned above, the network communication model generator 120 cangenerate the network communication model 104 with the followingconstraints:

(1) The rules in the model 104 should accurately reflect the actuallyobserved network communications, as represented by the match data 118.

(2) The match data 118 can be the sole source of the data that thenetwork communication model generator 120 uses to generate the networkcommunication model 104, and the match data 118 may not contain anylabels or other a priori information about which communicationsrepresented by the match data 118 are healthy or unhealthy. The networkcommunication model generator 120 can, therefore, learn which observedcommunications are healthy and which are unhealthy without any such apriori information. This is an example of an “unsupervised” learningproblem.

(3) The resulting rules in the network communication model 104 shouldallow for natural generalizations of the observed network communicationsrepresented by the match data 118, but not allow novel applications tocommunicate on the network without constraint. The rules, in otherwords, should minimize the number of misses (i.e., unhealthycommunications which the model 104 does not identify as unhealthy), eventhough the match data 118 may represent few if any, unhealthycommunications and any unhealthy communications which are represented bythe match data 118 may not be labeled as such.

(4) The model 104 should be in a form that humans can read, understand,and modify, even if doing so requires significant dedication andattention. Most existing machine learning algorithms are not adequate toproduce rules which satisfy this constraint, because they tend to createcomplex, probabilistic outputs that people—even experts—find dauntingeven to understand, much less to modify.

(5) The match data 118 can contain billions of matches, resulting frommonths of matches collected from a medium-to-large corporate networkcontaining thousands of systems. The network communication modelgenerator 120, therefore, should be capable of processing such “bigdata” to produce the network communication model 104. It may not, forexample, be possible to load all of the match data 118 into memory on asingle computer. As a result, it may be necessary to use one or both ofthe following:

(a) Algorithms that process the match data 118 in a distributed fashion,such as MapReduce.

(b) Algorithms that process data in a streaming fashion by using aprocessor to sequentially read the data and then to update the model 104and then forget (e.g., delete) the data that it has processed.

Not all embodiments need to satisfy, or even attempt to satisfy, all ofthe constraints listed above. Certain embodiments of the presentinvention may, for example, only even attempt to satisfy fewer than all(e.g., two, three, or four) of the constraints listed above. Regardlessof the number of constraints that a particular embodiment attempts tosatisfy, the embodiment may or may not satisfy all such constraints inits generation of the resulting model 104 and may satisfy differentconstraints to greater or lesser degrees. For example, the model 104that results from some embodiments may be easily understandable andmodifiable by a human, while the model 104 that results from otherembodiments of the present invention may be difficult for a human tounderstand and modify.

The resulting model 104 can, for example, be or contain a set of rules,each of which may be or contain a set of feature-value pairs. A rulewithin the model 104 may, for example, contain feature-value pairs ofthe kind described above in connection with an example flow (e.g.,timestamp: 1481364002.234234; id: 353530941). The term “accept” is usedherein in connection with a rule R and a match M as follows: a rule R“accepts” a match M if, for each feature-value pair (F, V) in rule R,match M also contains the feature F with the value V. As a result, ruleR will accept match M if the set of feature-value pairs in rule R is asubset of the set of feature-value pairs in match M. Furthermore, if atleast one rule in the model 104 accepts match M, then the match isaccepted by the set of rules.

Network Communication Policies

With the resulting model 104, the system 50 can utilize a policymanagement engine 130 to develop policies 132, 134 a, 134 b foracceptable network communication, i.e., for microsegmentation. Thepolicy management engine 130 can receive the model 104. The model 104includes state information that can include both application stateinformation and network topology information (e.g., addresses, listeningports, broadcast zones). The policy management engine 130 can, forexample, store such state information in a log (e.g., database) of stateinformation received from one or more local security agents (e.g.,agents 106 a-b) over time. Such a log can include, for each unit ofstate information received, an identifier of the system (e.g., sourcesystem 102 a or destination system 102 b) from which the stateinformation was received. In this way, the policy management engine 130can build and maintain a record of application state and networkconfiguration information from various systems over time.

The policy management engine 130 can include or otherwise have access toa set of policies 132, which may be stored in the cloud-based system100. In general, each of the policies 132 specifies both a sourceapplication and a destination application and indicates that the sourceapplication is authorized (or not authorized) to communicate with thedestination application. A policy may specify, for the source and/ordestination application, any number of additional attributes of thesource and/or destination application, such as any one or more of thefollowing, in any combination: user(s) who are executing the application(identified, e.g., by username, group membership, or anotheridentifier), system(s), network subnet, and time(s). A policy canidentify its associated source and/or destination application by itsname and any other attribute(s) which may be used to authenticate thevalidity and identify of an application, such as any one or more of thefollowing in any combination: filename, file size, a cryptographic hashof contents, and digital code signing certificates associated with theapplication. A policy can include other information for its associatedsource and/or destination application, such as the IP address and portused by the application to communicate, whether or not such informationis used to define the application.

The policy management engine 130 provides, to one or more systems in thesystem 50 (e.g., the source system 102 a and destination system 102 b),policy data, obtained and/or derived from the policies, representingsome or all of the policies that are relevant to the system to which thepolicy data is transmitted, which may include translating applicationsinto IP address/port combinations. For example, the policy managementengine 130 can identify a subset of the policies 132 that are relevantto the source system 102 a and the destination system 102 b and transmitpolicies 134 a, 134 b accordingly. The systems 102 a, 102 b receive andstore the policies 134 a, 134 b. The policy management engine 130 canidentify the subset of the policies 132 that are relevant to aparticular system (e.g., the source system 102 a and/or the destinationsystem 102 b) in any of a variety of ways, including based on the model104.

The policy management engine 130 can extract the policy data that isrelevant to the systems 102 a, 102 b in response to any of a variety oftriggers, such as periodically (e.g., every second, every minute, or atany scheduled times); in response to a change in the master policy data;in response to a change in network topology, e.g., an assignment of anetwork address to one of the systems 102 a-b or a change in anassignment of an existing address; in response to a new applicationexecuting on one of the systems 102 a-b; in response to an existingapplication in the system 50 changing or adding a port on which it islistening for connections; and in response to an unexpected condition onsystems 102 a-b or other systems in the network.

The system 50 can operate in one of at least three security modes inrelation to any particular connection between two applications (e.g.,the source application 104 a and the destination application 104 b):

(1) Optimistic: The connection between the two applications is allowedunless and until a reconciliation engine instructs the agents 106 a-bassociated with those applications to terminate the connection due to apolicy violation.

(2) Pessimistic: The connection between the two applications isterminated after a specified amount of time has passed if thereconciliation engine does not affirmatively instruct the agentsassociated with those applications to keep the connection alive.

(3) Blocking: The connection between the two applications is blockedunless and until the reconciliation engine affirmatively instructs theagents associated with those applications to allow the connection.

Note that the system 50 may, but need not, operate in the same securitymode for all connections within the system 50. The system 50 can, forexample, operate in optimistic security mode for some connections,operate in pessimistic security mode for other connections, and operatein blocking security mode for yet other connections. As yet anotherexample, the system 50 can switch from one mode to another for any givenconnection or set of connections in response to detected conditions, aswill be described in more detail below.

Automated Microsegmentation

With the network communication model 104 and the network communicationpolicies 132, the system 50 can include automatic microsegmentation, asillustrated in FIG. 2 . Of note, machine learning is ideal for detectingnormal (healthy) and abnormal (unhealthy) communications and is idealfor automating microsegmentation. That is, the model 104 and thepolicies 132 can be used to automatically create microsegments in thesystem 50.

FIG. 4 is a flowchart of an automated microsegmentation process 140. Theautomated microsegmentation process 140 contemplates operation via thesystem 50. The automated microsegmentation process 140 includes buildingsegments (step 141), creating segment policies (step 142), autoscalinghost segments (step 143), upgrading applications (step 144), anddeploying new applications (step 145). The steps 141, 142 can beimplemented via the cloud-based system 100 based on the communicationsin the system 50. These steps include machine learning to develop themodel 104 and the policies 132. After steps 141, 142, the automatedmicrosegmentation process 140 contemplates dynamic operation toautoscale segments as needed, and to identify upgraded applications andnewly deployed applications.

The system 50 and the automated microsegmentation process 140advantageously performs the vast majority of the work required tomicrosegment the network automatically, possibly leaving only the taskof review and approval to the user. This saves a significant amount oftime and increases the quality of the microsegmentation compared tomicrosegmentation solely performed manually by one or more humans.

In general, automated microsegmentation process 140 can perform some orall of the following steps to perform microsegmenting of a network:

(a) Automatically surveying the network to find its functionalcomponents and their interrelations.

(b) Automatically creating one or more subgroups of hosts on thenetwork, where each subgroup corresponds to a functional component. Eachsuch subgroup is an example of a microsegment. A functional componentmay, for example, be or include a set of hosts that are similar to eachother, as measured by one or more criteria. In other words, all of thehosts in a particular functional component may satisfy the samesimilarity criteria as each other. For example, if a set of hostscommunicate with each other much more than expected, in comparison tohow much they communicate with other hosts, then embodiments can definethat set of hosts as a functional component and as a microsegment. Asanother example, if hosts in a first set of hosts communicate with hostsin a second set of hosts, then embodiments can define the first set ofhosts as a functional component and as a microsegment, whether or notthe first set of hosts communicates amongst themselves. As yet anotherexample, embodiments can define a set of hosts that have the same set ofsoftware installed on them (e.g., operating system and/or applications)as a functional component and as a microsegment. “Creating,” “defining,”“generating,” “identifying” a microsegment may, for example, includedetermining that a plurality of hosts satisfy particular similaritycriteria, and generating and storing data indicating that the identifiedplurality of hosts form a particular microsegment.

(c) For each microsegment identified above, automatically identifyingexisting network application security policies that control access tohosts in that microsegment. For example, embodiments of the presentinvention may identify existing policies that govern (e.g., allow and/ordisallow) inbound connections (i.e., connections into the microsegment,for which hosts in the microsegment are destinations) and/or existingpolicies that govern (e.g., allow and/or disallow) for outboundconnections (i.e., connections from the microsegment, for which hosts inthe microsegment are sources). If the microsegmentation(s) weregenerated well, then the identified policies may govern connectionsbetween microsegments, in addition to individual hosts inside andoutside each microsegment.

(d) Providing output to a human user representing each definedmicrosegment, such as by listing names and/or IP addresses of the hostsin each of the proposed microsegments. This output may be provided, forexample, through a programmatic Application Program Interface (API) toanother computer program or by providing output directly through a userinterface to a user.

(e) Receiving input from the user in response to the output representingthe microsegment. If the user's input indicates approval of themicrosegment, then embodiments of the present invention may, inresponse, automatically enforce the identified existing networkapplication policies that control access to hosts in the now-approvedmicrosegment. If the user's input does not indicate approval of themicrosegment, then embodiments of the present invention may, inresponse, automatically not enforce the identified existing networkapplication policies that control access to hosts in the now-approvedmicrosegment.

In prior art approaches (FIG. 1 ), most or all steps in themicrosegmenting process are performed manually and can be extremelytedious, time-consuming, and error-prone for humans to perform. Whensuch functions are otherwise attempted to be performed manually, theycan involve months or even years of human effort, and often they arenever completed. One reason for this is the task's inherent complexity.Another reason is that no network is static; new hosts and newfunctional requirements continue to rise over time. If microsegmentationpolicies are not updated over time, those new requirements cannot besatisfied, and the existing microsegmentations become obsolete andpotentially dangerously insecure.

Embodiments of the present invention improve upon the prior art byperforming a variety of functions above automatically and therebyeliminating the need for human users to perform those functionsmanually, such as:

automatically defining the sets of source and destination networkhost-application pairs that are involved in the policies to be appliedto the microsegment;

automatically establishing the desired behavior in the microsegment,including but not limited to answering the questions: (a) are thepolicies that apply to the microsegment intended to allow or to blockcommunications between the two host-application sets; and (b) are thepolicies that apply to the microsegment intended to allow or blockcommunications within the host-application sets?; and

automatically configuring and applying rules for each of the desiredbehaviors above so that they can be executed by the agents on the hosts.The automated microsegmentation process 140 can repeat multiple timesover time: identifying (or updating existing) microsegments; identifyingupdated network application security policies and applying those updatedpolicies to existing or updated microsegments; prompting the user forapproval of new and/or updated microsegments; and applying theidentified network application security policies only if the userapproves of the new and/or updated microsegments.

Example Cloud-Based System Architecture

FIG. 5 is a network diagram of a cloud-based system 100 offeringsecurity as a service. Specifically, the cloud-based system 100 canoffer a Secure Internet and Web Gateway as a service to various users145 (e.g., the systems 102 a-b), as well as other cloud services. Inthis manner, the cloud-based system 100 is located between the users 145and the Internet as well as any cloud services (or applications)accessed by the users 145. As such, the cloud-based system 100 providesinline monitoring inspecting traffic between the users 145, theInternet, and the cloud services, including Secure Sockets Layer (SSL)traffic. The cloud-based system 100 can offer access control, threatprevention, data protection, etc. The access control can include acloud-based firewall, cloud-based intrusion detection, Uniform ResourceLocator (URL) filtering, bandwidth control, Domain Name System (DNS)filtering, etc. The threat prevention can include cloud-based intrusionprevention, protection against advanced threats (malware, spam,Cross-Site Scripting (XSS), phishing, etc.), cloud-based sandbox,antivirus, DNS security, etc. The data protection can include Data LossPrevention (DLP), cloud application security such as via a Cloud AccessSecurity Broker (CASB), file type control, etc.

The cloud-based firewall can provide Deep Packet Inspection (DPI) andaccess controls across various ports and protocols as well as beingapplication and user aware. The URL filtering can block, allow, or limitwebsite access based on policy for a user, group of users, or entireorganization, including specific destinations or categories of URLs(e.g., gambling, social media, etc.). The bandwidth control can enforcebandwidth policies and prioritize critical applications such as relativeto recreational traffic. DNS filtering can control and block DNSrequests against known and malicious destinations.

The cloud-based intrusion prevention and advanced threat protection candeliver full threat protection against malicious content such as browserexploits, scripts, identified botnets and malware callbacks, etc. Thecloud-based sandbox can block zero-day exploits (just identified) byanalyzing unknown files for malicious behavior. Advantageously, thecloud-based system 100 is multi-tenant and can service a large volume ofthe users 145. As such, newly discovered threats can be promulgatedthroughout the cloud-based system 100 for all tenants practicallyinstantaneously. The antivirus protection can include antivirus,antispyware, antimalware, etc. protection for the users 145, usingsignatures sourced and constantly updated. The DNS security can identifyand route command-and-control connections to threat detection enginesfor full content inspection.

The DLP can use standard and/or custom dictionaries to continuouslymonitor the users 145, including compressed and/or SSL-encryptedtraffic. Again, being in a cloud implementation, the cloud-based system100 can scale this monitoring with near-zero latency on the users 145.The cloud application security can include CASB functionality todiscover and control user access to known and unknown cloud services106. The file type controls enable true file type control by the user,location, destination, etc. to determine which files are allowed or not.

In an embodiment, the cloud-based system 100 includes a plurality ofenforcement nodes (EN) 150, labeled as enforcement nodes 150-1, 150-2,150-N, interconnected to one another and interconnected to a centralauthority (CA) 152. The nodes 150 and the central authority 152, whiledescribed as nodes, can include one or more servers, including physicalservers, virtual machines (VM) executed on physical hardware, etc. Anexample of a server is illustrated in FIG. 6 . The cloud-based system100 further includes a log router 154 that connects to a storage cluster156 for supporting log maintenance from the enforcement nodes 150. Thecentral authority 152 provide centralized policy, real-time threatupdates, etc. and coordinates the distribution of this data between theenforcement nodes 150. The enforcement nodes 150 provide an onramp tothe users 145 and are configured to execute policy, based on the centralauthority 152, for each user 145. The enforcement nodes 150 can begeographically distributed, and the policy for each user 145 followsthat user 145 as he or she connects to the nearest (or other criteria)enforcement node 150.

The enforcement nodes 150 are full-featured secure internet gatewaysthat provide integrated internet security. They inspect all web trafficbi-directionally for malware and enforce security, compliance, andfirewall policies, as described herein, as well as various additionalfunctionality. In an embodiment, each enforcement node 150 has two mainmodules for inspecting traffic and applying policies: a web module and afirewall module. The enforcement nodes 150 are deployed around the worldand can handle hundreds of thousands of concurrent users with millionsof concurrent sessions. Because of this, regardless of where the users145 are, they can access the Internet from any device, and theenforcement nodes 150 protect the traffic and apply corporate policies.The enforcement nodes 150 can implement various inspection enginestherein, and optionally, send sandboxing to another system. Theenforcement nodes 150 include significant fault tolerance capabilities,such as deployment in active-active mode to ensure availability andredundancy as well as continuous monitoring.

The central authority 152 hosts all customer (tenant) policy andconfiguration settings. It monitors the cloud and provides a centrallocation for software and database updates and threat intelligence.Given the multi-tenant architecture, the central authority 152 isredundant and backed up in multiple different data centers. Theenforcement nodes 150 establish persistent connections to the centralauthority 152 to download all policy configurations. When a new userconnects to an enforcement node 150, a policy request is sent to thecentral authority 152 through this connection. The central authority 152then calculates the policies that apply to that user 145 and sends thepolicy to the enforcement node 150 as a highly compressed bitmap.

The cloud-based system 100 can be a private cloud, a public cloud, acombination of a private cloud and a public cloud (hybrid cloud), or thelike. Cloud computing systems and methods abstract away physicalservers, storage, networking, etc., and instead offer these as on-demandand elastic resources. The National Institute of Standards andTechnology (NIST) provides a concise and specific definition whichstates cloud computing is a model for enabling convenient, on-demandnetwork access to a shared pool of configurable computing resources(e.g., networks, servers, storage, applications, and services) that canbe rapidly provisioned and released with minimal management effort orservice provider interaction. Cloud computing differs from the classicclient-server model by providing applications from a server that areexecuted and managed by a client's web browser or the like, with noinstalled client version of an application required. Centralizationgives cloud service providers complete control over the versions of thebrowser-based and other applications provided to clients, which removesthe need for version upgrades or license management on individual clientcomputing devices. The phrase “Software as a Service” (SaaS) issometimes used to describe application programs offered through cloudcomputing. A common shorthand for a provided cloud computing service (oreven an aggregation of all existing cloud services) is “the cloud.” Thecloud-based system 100 is illustrated herein as an example embodiment ofa cloud-based system, and other implementations are also contemplated.

As described herein, the terms cloud services and cloud applications maybe used interchangeably. A cloud service is any service made availableto users on-demand via the Internet, as opposed to being provided from acompany's on-premises servers. A cloud application, or cloud app, is asoftware program where cloud-based and local components work together.The cloud-based system 100 can be utilized to provide example cloudservices, including Zscaler Internet Access (ZIA), Zscaler PrivateAccess (ZPA), and Zscaler Digital Experience (ZDX), all from Zscaler,Inc. (the assignee and applicant of the present application). Also,there can be multiple different cloud-based systems 100, including oneswith different architectures and multiple cloud services. The ZIAservice can provide the access control, threat prevention, and dataprotection described above with reference to the cloud-based system 100.ZPA can include access control, microservice segmentation, etc. The ZDXservice can provide monitoring of user experience, e.g., Quality ofExperience (QoE), Quality of Service (QoS), etc., in a manner that cangain insights based on continuous, inline monitoring. For example, theZIA service can provide a user with Internet Access, and the ZPA servicecan provide a user with access to enterprise resources instead oftraditional Virtual Private Networks (VPNs), namely ZPA provides ZeroTrust Network Access (ZTNA). Those of ordinary skill in the art willrecognize various other types of cloud services are also contemplated.Also, other types of cloud architectures are also contemplated, with thecloud-based system 100 presented for illustration purposes.

The cloud-based system 100 can communicate with a plurality of agents106 in the system 50 to provide microsegmentation as a service. Also,the cloud-based system 100 can include a management interface 158 for ITusers to interact with the system 50.

In the present disclosure, the cloud-based system 100 can be used toprovide some service to users in a serverless computing manner, from theperspective of the users. In such a case, serverless applications 108operating in the serverless computing manner will not have the agents106. As is described in detail herein, the serverless applications 108will have a networking ACL, or simply ACL, associated therewith, and themicrosegmentation as a service is provided through configuration of thisACL appropriately.

Example Server Architecture

FIG. 6 is a block diagram of a server 200, which may be used in thecloud-based system 100, in other systems, or standalone. For example,the enforcement nodes 150 and the central authority 152 may be formed asone or more of the servers 200. Further, the systems 102 a-b may alsohave a similar architecture as the server 200. The server 200 may be adigital computer that, in terms of hardware architecture, generallyincludes a processor 202, input/output (I/O) interfaces 204, a networkinterface 206, a data store 208, and memory 210. It should beappreciated by those of ordinary skill in the art that FIG. 6 depictsthe server 200 in an oversimplified manner, and a practical embodimentmay include additional components and suitably configured processinglogic to support known or conventional operating features that are notdescribed in detail herein. Also, the server 200, in general, may bereferred to as a processing device. The components (202, 204, 206, 208,and 210) are communicatively coupled via a local interface 212. Thelocal interface 212 may be, for example, but not limited to, one or morebuses or other wired or wireless connections, as is known in the art.The local interface 212 may have additional elements, which are omittedfor simplicity, such as controllers, buffers (caches), drivers,repeaters, and receivers, among many others, to enable communications.Further, the local interface 212 may include address, control, and/ordata connections to enable appropriate communications among theaforementioned components.

The processor 202 is a hardware device for executing softwareinstructions. The processor 202 may be any custom made or commerciallyavailable processor, a Central Processing Unit (CPU), an auxiliaryprocessor among several processors associated with the server 200, asemiconductor-based microprocessor (in the form of a microchip orchipset), or generally any device for executing software instructions.When the server 200 is in operation, the processor 202 is configured toexecute software stored within the memory 210, to communicate data toand from the memory 210, and to generally control operations of theserver 200 pursuant to the software instructions. The I/O interfaces 204may be used to receive user input from and/or for providing systemoutput to one or more devices or components.

The network interface 206 may be used to enable the server 200 tocommunicate on a network, such as the Internet. The network interface206 may include, for example, an Ethernet card or adapter or a WirelessLocal Area Network (WLAN) card or adapter. The network interface 206 mayinclude address, control, and/or data connections to enable appropriatecommunications on the network. A data store 208 may be used to storedata. The data store 208 may include any of volatile memory elements(e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and thelike)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM,and the like), and combinations thereof.

Moreover, the data store 208 may incorporate electronic, magnetic,optical, and/or other types of storage media. In one example, the datastore 208 may be located internal to the server 200, such as, forexample, an internal hard drive connected to the local interface 212 inthe server 200. Additionally, in another embodiment, the data store 208may be located external to the server 200 such as, for example, anexternal hard drive connected to the I/O interfaces 204 (e.g., SCSI orUSB connection). In a further embodiment, the data store 208 may beconnected to the server 200 through a network, such as, for example, anetwork-attached file server.

The memory 210 may include any of volatile memory elements (e.g., randomaccess memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatilememory elements (e.g., ROM, hard drive, tape, CDROM, etc.), andcombinations thereof. Moreover, the memory 210 may incorporateelectronic, magnetic, optical, and/or other types of storage media. Notethat the memory 210 may have a distributed architecture, where variouscomponents are situated remotely from one another but can be accessed bythe processor 202. The software in memory 210 may include one or moresoftware programs, each of which includes an ordered listing ofexecutable instructions for implementing logical functions. The softwarein the memory 210 includes a suitable Operating System (O/S) 214 and oneor more programs 216. The operating system 214 essentially controls theexecution of other computer programs, such as the one or more programs216, and provides scheduling, input-output control, file and datamanagement, memory management, and communication control and relatedservices. The one or more programs 216 may be configured to implementthe various processes, algorithms, methods, techniques, etc. describedherein.

Fingerprinting

In an embodiment, the system 50 can include cryptographic identity ofworkloads for identifying communications, authorizing communications,etc. The cryptographic identity is used to verify software and/ormachine identity, i.e., the identify of the applications 108 and theidentity of the systems 102. The cryptographic identity can be referredto as a device or application fingerprint. Importantly, thecryptographic identity is based on multiple characteristics to ensureunique identification and prevent spoofing. The cryptographic identitycan based on a combination of any of the following:

Software Host Network Hash (SHA256) Operating System Network namespaceLocality Sensitive Provisioned Hostname IP Address Hash (LSH) ExecutableSigning BIOS UUID Port Portable Executable CPU Serial numbers Protocol(PE) Header values Process Identifiers User ID MAC AddressContainer/Image ID Other hardware parameters

Also, the cryptographic identity can include values based on SoftwareReputation, Behavioral Scoring, Capabilities Classification, and thelike. FIG. 7 is a block diagram of two systems 102 communicating to oneanother and their example cryptographic identities, i.e., fingerprints.A key aspect of the cryptographic identity is its resilience to softwareupgrades and Continuous Integration/Continuous Deployment (CI/CD).

For example, a descriptive of device fingerprinting is provided incommonly assigned U.S. Patent Publication No. 20200077265, filed Nov. 5,2019, and entitled “Device identification for management and policy inthe cloud,” the contents of which are incorporated by reference in theirentirety.

Segment Naming

Again, the microsegmentation described herein describes the automaticgeneration of segments for zero trust between hosts and betweenapplications. The following descriptions use the terms hosts andapplications. As described herein, the hosts are the systems 102, theservers 200, etc. A host is any type of computing device on a networkand part of the system 50 and including the agent 106. Those of ordinaryskill in the art will recognize a host can include a server computer,desktop computer, laptop computer, tablet computer, smartphone, wearablecomputer, database, storage cluster, Internet of Things (IoT) device,printer, and the like. As described herein, the applications areexecuted on the hosts and can include the applications 108. Theapplications 108 can be anything that generates network communicationdata and is used for microsegmentation.

The foregoing describes the ability to create groups (segments) of hosts(i.e., the systems 102) and groups (collections) of applications 108.There is a need for management to provide a human-readable name for theautomatically generated segments, especially segments between hosts.Problematically, the raw materials do not make this simple or easy tounderstand. The easiest source of information is the name of theindividual hosts. That is, the name that the host calls itself, i.e.,the hostname. However, those need only be random strings (e.g.,DESKTOP-RGK97GG), unless someone (an administrator) cares enough to makethem informative. Even if the hostnames contain human intentioninformation, it is not obvious how to (a) recognize that intention (thisis pretty much an Artificial Intelligence (AI)-complete problem) and/or(b) how to combine those strings to make another string that describesthe hosts in the segment collectively. Another source of information isthe name that other hosts use to refer to a host. There may be severalof these, assigned by a centralized Domain Name Controller (DNC). Theproblem is the system 50 for microsegmentation does not necessarily haveaccess to the DNC.

Again, as described in the background and FIG. 1 , the manual approachto microsegmentation is time-consuming, changes often as the networkevolves, and prone to mistakes. The present disclosure contemplatesautomated microsegmentation. However, network administrators (i.e., ITpersonnel) may be uncomfortable with turning network microsegmentationcontrol over to an automated process. To that end, the presentdisclosure provides an automatic network segment naming approach. Again,advantageously, providing a meaningful name encourages networkadministrators to utilize the automation of microsegmentation as theycan understand and manage the various automatically created segments.

Automated Microsegmentation and Segment Naming Process

FIG. 8 is a flowchart of an automated microsegmentation and segmentnaming process 300. The automated microsegmentation and segment namingprocess 300 can be implemented as a method, as a non-transitorycomputer-readable medium storing computer-executable instructions that,when executed, cause a processor to perform the steps, via the system 50for generating network application security policies, and/or via thecloud-based system 100. The automated microsegmentation and segmentnaming process 300 includes obtaining network communication informationabout hosts in a network and applications executed on the hosts (step301); automatically generating one or more microsegments in the networkbased on analysis of the obtained network communication information,wherein each microsegment of the one or more microsegments is a groupingof resources including the hosts and the applications executed on thehosts that have rules for network communication (step 302);automatically generating a meaningful name for the one or moremicrosegments based on a plurality of techniques applied to informationassociated with the hosts (step 303); and displaying the automaticallygenerated one or more microsegments and the corresponding automaticallygenerated meaningful name (step 304).

The automated microsegmentation and segment naming process 300 canfurther include obtaining updated network communication informationabout the hosts and the applications; and updating the automaticallygenerated one or more microsegments and/or generating new microsegmentsin the network based on analysis of the obtained updated information.That is, because of the automated nature, the automatedmicrosegmentation and segment naming process 300 can operatecontinuously, periodically, on demand, etc. to update the network 10 andthe associated segments. The automated microsegmentation and segmentnaming process 300 can further include providing details of the one ormore microsegments and the rules to the hosts and/or applications in thenetwork. Each of the hosts can include an agent executed thereon thatprovides the information to the processing device. The agent isconfigured to enforce the rules for network communication.

The plurality of techniques can include any of use of a stringsimilarity among hostnames of the hosts in a given microsegment, use ofmetadata, excluding hostnames, associated with the hosts, and use ofnames of the applications in a given microsegment. The string similaritycan include first utilizing a largest substring all the hosts in thegiven microsegment share, and second utilizing one of a second substringif the largest substring is shared by other segments and the largestsubstring plus an additional string appended thereto if the largestsubstring is shared by other segments.

For string similarity among hostnames, suppose, for a host segment,there is a list of the hostnames that hosts have for themselves. It ispossible to look for the shared substrings that those hostnames share.For example, if there was a host segment with four hosts with thehostnames:

SFO-BACKUP-DB-1 SFO-PROCESSING-1 SFO-SERVER-1 SFO-DATABASE-1

It is possible to decide that “SFO-” was a reasonable name for this hostsegment, since it is the largest substring that all the hosts share.Also, there might be other conditions that the substring should satisfy(initialness, meaningfulness, length, alphabetic characters, etc.) tomake it more valuable as a name. That is, this technique can parse forthe largest substring that is shared. It can also look for the largestsubstring that may be shared by the most hosts, i.e., not all hosts mustinclude this substring. It is also that it may be a subset of thislargest substring that satisfies the other conditions. In the aboveexample, the largest substring “SFO-” may be shortened to “SFO,” i.e.,removal of the “-” as this does not convey any meaningful information.

This largest substring might also be affected by names given to otherhost segments. If more than one host segment has “SFO-” (or “SFO”) as anassigned name, then there is a need to distinguish them in some otherway. One way is to choose the next most valuable substring name for oneof the host segments, if one of the host segments has a second-mostvaluable name that is not much worse than the most valuable one.Alternatively, it is possible to append something random to the segmentnames, to distinguish them. It is preferable to fall back to asecond-best name if there is one and it is “good enough” and it isdistinct from all the other selected names. It is possible to use a“cuckoo” process here: that is, if there is a need to change segment A'sname, and A's new name is similar to segment B's name, then adopt thatnew name for segment A and also force segment B to change its name.(And, possibly, so on, until the naming process stabilizes.)

Also, the techniques can use other host information besides thehostname. There are a couple of other sources for name information fromwhich it is possible to create meaningful segment names. One type ofsource is host metadata, such as IP addresses, host Operating Systemnames, DNS information, etc.

Another type of information is the set of communicating applications oneach host. In particular, the traffic among the hosts in the segment isknown as is the traffic from the hosts in the segment to hosts outsidethe segment. It is possible to combine these to find a combination ofapplication names that characterize the host segment—in terms of whatapplications are commonly communicating within the segment, and whichapplications are communicating from the segment to other segments.

Auto Segmentation

In an embodiment, the cloud-based system 100 (or some other computersystem) automatically generates a proposal for performingmicrosegmentation on a network. The system 100 provides outputrepresenting the proposed microsegmentation to a user. The user providesinput either approving or disapproving of the proposedmicrosegmentation. If the user approves of the proposedmicrosegmentation, then the system 100 implements the microsegmentation.This process may be repeated for a plurality of proposedmicrosegmentations within the same network, and may be repeated overtime to modify one or more existing microsegmentations. The system 100advantageously performs the vast majority of the work required tomicrosegment the network automatically, leaving only the task of reviewand approval to the user; of course, this user approval step can beomitted for auto segmentations. This both saves a significant amount oftime and increases the quality of the microsegmentation in comparison tomicrosegmentation solely performed manually by one or more humans.

This application is related to the following patent applications, bothof which are incorporated by reference herein:

-   -   application Ser. No. 15/883,534, filed on Jan. 30, 2018,        entitled, “Network Application Security Policy Enforcement,” now        U.S. Pat. No. 10,154,067, issued on Dec. 11, 2018 (hereinafter        “the Policy Enforcement Patent”); and    -   U.S. patent application Ser. No. 15/899,453, filed on Feb. 20,        2018 entitled, “Network Application Security Policy Generation,”        now U.S. Pat. No. 10,439,985, issued on Oct. 8, 2019        (hereinafter “the Policy Generation Patent”).

As described in the Policy Enforcement Patent and the Policy GenerationPatent, information may be collected automatically about applicationsexecuting on a network, and network security policies may be generatedautomatically based on the collected information. Such policies may thenbe enforced at the application and host level within the network. Aswill be described in more detail below, embodiments may group suchpolicies together to define and secure a proposed microsegment (alsoreferred to herein as a “microsegmentation”), which may then be put intoeffect without requiring human effort except maybe for a review andapproval of the proposed microsegment. Such approval may include aslittle as a single gesture (such as a single click or tap on a userinterface element, such as an “OK” button), hitting a single key, ortyping or speaking a single word or phrase.

In general, embodiments may perform some or all of the following stepsto perform microsegmenting of a network:

(a) Automatically surveying the network to find its functionalcomponents and their interrelations.

(b) Automatically creating one or more subgroups of hosts on thenetwork, where each subgroup corresponds to a functional component. Eachsuch subgroup is an example of a microsegment. A functional componentmay, for example, be or include a set of hosts that are similar to eachother, as measured by one or more criteria. In other words, all of thehosts in a particular functional component may satisfy the samesimilarity criteria as each other. For example, if a set of hostscommunicate with each other much more than expected, in comparison tohow much they communicate with other hosts, then embodiments of thepresent invention may define that set of hosts as a functional componentand as a microsegment. As another example, if hosts in a first set ofhosts communicate with hosts in a second set of hosts, then embodimentsof the present invention may define the first set of hosts as afunctional component and as a microsegment, whether or not the first setof hosts communicates amongst themselves. As yet another example,embodiments of the present invention may define a set of hosts that havethe same set of software installed on them (e.g., operating systemand/or applications) as a functional component and as a microsegment.“Creating,” “defining,” “generating,” “identifying” a microsegment may,for example, include determining that a plurality of hosts satisfyparticular similarity criteria, and generating and storing dataindicating that the identified plurality of hosts form a particularmicrosegment.(c) For each microsegment identified above, automatically identifyingexisting network application security policies that control access tohosts in that microsegment. For example, embodiments of the presentinvention may identify existing policies that govern (e.g., allow and/ordisallow) inbound connections (i.e., connections into the microsegment,for which hosts in the microsegment are destinations) and/or existingpolicies that govern (e.g., allow and/or disallow) for outboundconnections (i.e., connections from the microsegment, for which hosts inthe microsegment are sources). If the microsegmentation(s) weregenerated well, then the identified policies may govern connectionsbetween microsegments, in addition to individual hosts inside andoutside each microsegment.(d) Providing output to a human user representing each definedmicrosegment, such as by listing names and/or IP addresses of the hostsin each of the proposed microsegments. This output may be provided, forexample, through a programmatic API to another computer program or byproviding output directly through a user interface to a user.(e) Receiving input from the user in response to the output representingthe microsegment. If the user's input indicates approval of themicrosegment, then embodiments of the present invention may, inresponse, automatically enforce the identified existing networkapplication policies that control access to hosts in the now-approvedmicrosegment. If the user's input does not indicate approval of themicrosegment, then embodiments of the present invention may, inresponse, automatically not enforce the identified existing networkapplication policies that control access to hosts in the now-approvedmicrosegment.

Conventionally, most or all steps in the microsegmenting process areperformed manually and can be extremely tedious, time-consuming, anderror prone for humans to perform. Embodiments of the present inventionimprove upon the prior art by performing a variety of functions aboveautomatically and thereby eliminating the need for human users toperform those functions manually, such as:

-   -   automatically defining the sets of source and destination        network host-application pairs that are involved in the policies        to be applied to the microsegment;    -   automatically establishing the desired behavior in the        microsegment, including but not limited to answering the        questions: (a) are the policies that apply to the microsegment        intended to allow or to block communications between the two        host-application sets; and (b) are the policies that apply to        the microsegment intended to allow or block communications        within the host-application sets?; and    -   automatically configuring and applying rules for each of the        desired behaviors above so that they can be executed by the        agents on the hosts.

More specifically, embodiments automatically identify proposedmicrosegments, and then:

-   -   Receive input from the user indicating whether the user approves        of each proposed microsegment. Such input may, for example, be        binary for each microsegment, such as an input indicating        “approve” or “disapprove.” The input may consist of a single        gesture, such as a single click or tap (e.g., on an “approve” or        “OK” button). The user may provide separate input for each of        one or more of the proposed microsegments, or may provide a        single input that applies to some or all of the proposed        microsegments. For example, the user may provide a single        “approve” input that applies to all of the proposed        microsegments.    -   In response to receiving input from the user approving of one or        more proposed microsegments, enforcing the policies that define        and protect the approved microsegment(s).

Because embodiments perform the functions above automatically (i.e.,without human intervention), the human user need only review theproposed microsegment(s) and approve or disapprove of them. When suchfunctions are otherwise attempted to be performed manually, they caninvolve months or even years of human effort, and often they are nevercompleted. One reason for this is the task's inherent complexity.Another reason is that no network is static; new hosts and newfunctional requirements continue to arise over time. Ifmicrosegmentation policies are not updated over time, those newrequirements cannot be satisfied, and the existing microsegmentationsbecome obsolete and potentially dangerously insecure.

To address changing hosts, network topologies, and network applicationsecurity policies over time, embodiments may repeat any of the methodsdisclosed herein over time. For example, embodiments may repeat themethods disclosed herein to perform any one or more of the followingfunctions multiple times over time:

-   -   identifying (or updating existing) microsegments;    -   identifying updated network application security policies and        applying those updated policies to existing or updated        microsegments;    -   prompting the user for approval of new and/or updated        microsegments; and    -   applying the identified network application security policies        only if the user approves of the new and/or updated        microsegments.

As just one example, embodiments may, at a first time, perform methodsdisclosed herein to create and receive the user's approval of aparticular microsegment and, in response to that approval, applyidentified network application security policies to that particularmicrosegment. Embodiments may then, at a second time that is later thanthe first time, perform methods disclosed herein to identify an updatedversion of a previously-approved microsegment (such as a version inwhich one or more hosts have been added to the microsegment).Embodiments may prompt the user for approval of the updatedmicrosegment. If the user's input indicates approval of the updatedmicrosegment, then embodiments of the present invention may apply theidentified network application security policies to the updatedmicrosegment. If, however, the user's input indicates disapproval of theupdated microsegment, then embodiments may not apply the identifiednetwork application security policies to the updated microsegment. Thisis an example in which embodiments may (in response to user approval)apply network application security policies to an earlier version of amicrosegment but not (in response to user disapproval) apply those (ordifferent0 network application security policies to a later version ofthe microsegment.

Embodiments may make use of the technology disclosed in the abovereferenced Policy Enforcement Patent and Policy Generation Patent. Thosedocuments disclose how to perform functions such as collectingapplication and host data, creating microsegments (also referred totherein as “collections”) and policies, and enforcing those policies.

FIG. 9 is a flowchart of an auto segmentation process 400 forautomatically proposing network microsegments and for, optionally,receiving human approval of those proposed microsegments. The system 50includes a network that may, for example, be implemented in any of theways disclosed in the Policy Enforcement Patent and/or the PolicyGeneration Patent. For example, the network may contain one or morehosts, also referred to herein as “systems 102.” A system 102 may, forexample, be a computer of any kind and may, therefore, include at leastone processor and at least one memory. The network may also containcomponents for collecting network information, which are showncollectively in FIG. 3 , and which are described in more detail in thePolicy Enforcement Patent. The network information collection module 104may collect network information from the network, such as by using anyof the techniques disclosed in the Policy Enforcement Patent (step 401).This is an example of what is referred to above as surveying the networkto find its functional components and their interrelations.

The system 100 also includes a microsegment generation module, whichreceives the network information as input, and which automaticallygenerates a set of proposed microsegments as output (step 402). Examplesof techniques that may be used by the microsegment generation module togenerate the proposed microsegments are disclosed in the PolicyGeneration Patent. The proposed microsegments may have any of thecharacteristics of microsegments disclosed herein.

The system 100 also includes a policy generation module, which receivesthe network information as input, and which automatically generates aset of policies 132 as output based on the flow matches in the networkinformation (step 403). The polices 132 are examples of policies thatcontrol access to the proposed microsegments. For example, a firstsubset of the policies 132 may control access to a first one of theproposed microsegments, while a second, different, subset of thepolicies 132 may control access to a second one of the proposedmicrosegments. Flows, flow matches, and examples of techniques that maybe used by the policy generation module to generate the policies 132 aredisclosed in the Policy Generation Patent.

The system 100 also includes a microsegment approval module, whichreceives the proposed microsegments and associated policies 132 asinput, and which generates, based on the proposed microsegments andpolicies 132, output to a human user representing some or all of theproposed microsegments and/or policies 132, such as by listing one ormore of: (1) names and/or IP addresses of the hosts in each of theproposed microsegments; and (2) descriptions of the policies 132, suchas flow matches (e.g., source and destination hosts and applications) inthe policies 132 (step 404).

The system 100 also includes a user input module, which receives inputfrom the user indicating whether the user approves of each of theproposed microsegments (step 405). Such input may, for example, bebinary for each of the microsegments, such as an input indicating“approve” or “disapprove.” The input may consist of a single gesture,such as a single click or tap (e.g., on an “approve” or “OK” button).The user may provide separate input for each of one or more of theproposed microsegments, or may provide a single input that applies tosome or all of the proposed microsegments. For example, the user mayprovide a single “approve” input that applies to all of the proposedmicrosegments. Of note, the human input may be optional and the proposedmicrosegments can be automatically implemented.

The system 100 also includes a policy enforcement module, which enforcesthe policies (from among the policies 132) that define and protect themicrosegment(s) that have been approved by the user, in response toreceiving the user's approval of those microsegment(s) (step 406). Thepolicy enforcement module receives output, which indicates whichmicrosegment(s), if any, the user has approved. If the user inputindicates that the user has not approved of any of the microsegment(s),then the policy enforcement module does not enforce any of the policiesthat control access to any of the proposed microsegments.

Auto Re-Segmentation to Assign New Applications

FIG. 10 is a flowchart of a process 450 for auto re-segmentation toassign new applications. The process 450 contemplates implementation asa method including steps, via a server 200 configured to implement thesteps, and where the steps are instructions stored in a non-transitorycomputer-readable medium.

The process 450 includes, subsequent to performing auto segmentation ona network that includes a set of policies of allowable and blockcommunications, observing communication between a plurality of hosts onthe network (step 451); determining unassigned communication paths basedon the observing that are either blocked because of a lack of a policyof the set of policies or because there is no policy of the set ofpolicies for coverage thereof (step 452); and assigning the unassignedcommunication paths to corresponding policies of the set of policies(step 453).

The assigning can be based on heuristics. The assigning can be performedwithout reperforming auto segmentation. The assigning can furtherinclude providing the unassigned communication paths to a user; andreceiving input from the user for the assigning. Each of thecommunication paths is a flow in the network where the flow iscommunication between a first application and a second application.

The auto segmentation can include obtaining network communicationinformation about the plurality of hosts in the network and applicationsexecuted on the plurality of hosts; and automatically generating one ormore microsegments in the network based on analysis of the obtainednetwork communication information, wherein each microsegment of the oneor more microsegments is a grouping of resources including the hosts andthe applications executed on the hosts that have rules for networkcommunication.

Each of the communication paths is a flow in the network where the flowis communication between a first application and a second application,wherein the communication between the first application and the secondapplication was not included in the network communication information.

Zero-Trust Identity-Based Protection of Datagram-Based Protocols

In an embodiment, the system 50 can operate with applications usingdatagram protocol packets. The present disclosure includes identifyingapplications are communicating with each other over a datagram protocol,determining which applications are capable of responding to unsoliciteddatagram protocol messages, and determines telemetry to gather.

For zero-trust access with datagram protocols, the present disclosureincludes:

1) A network security agent that enforces application identity-basedpolicy, e.g., the agent 106,

2) A mechanism to enforce sending and receiving of datagram protocolpackets on each of the systems 102,

3) Mechanism(s) that collect metadata about the packet's headers, theapplication(s) associated with the socket, and optionally an inexpensivechecksum of the payload, as packets transit a kernel's network stack,such as via the agent 106 on the systems 102,

4) A facility to correlate and merge related telemetry into a singleevent describing one (or more) UDP packets that flowed along a virtualcircuit defined by the source IP address, destination IP address, IPprotocol number, and whatever information the upper layer protocolrequires to uniquely identify a flow (e.g., in the case of UDP, thesource and destination port numbers),

5) A data processing and analytics platform that receives telemetry froma group of network security agents 106, such as in the cloud-basedsystem 100,

6) A facility to send the telemetry events from (4) to (5),

7) A mechanism within (5) that uses metadata in the telemetry eventsfrom (4) to uniquely identify virtual circuits in the network betweentwo application programs communicating with each other over a datagramprotocol, thereby constructing a graph of all application softwarecommunicating via datagram protocols over a network,

8) A mechanism within (1) that tracks kernel datagram protocol socketsas they open and close, sending notifications of these events to (5),

9) A mechanism within (5) that attempts to learn the low-level patternsof every application to determine which application programs are capableof responding to unsolicited datagram messages, which can be called“responders,”

10) A mechanism within (5) that uses the graph constructed by (7), andthe knowledge of which applications are “responders” from (9), to buildenforcement policies for each application that communicates with othersoftware over a datagram protocol, and

11) A mechanism within (1) for dynamically limiting the amount ofmetadata collected and transmitted to (5) for each datagram protocolvirtual circuit, based upon an estimated probability that the analyticssystem has already been successful in identifying matching telemetryfrom the security agent node at the other end of the datagram virtualcircuit.

FIG. 11 is a flowchart of a process 500 for application identity-basedenforcement of datagram protocols. The process 500 contemplatesimplementation as a method including steps, via a server 200 configuredto implement the steps, and where the steps are instructions stored in anon-transitory computer-readable medium.

The process 500 includes obtaining telemetry from a plurality ofsecurity agents each operating on a device in a network, wherein thetelemetry is collected locally related to datagram protocol packets(step 501); analyzing the telemetry to determine applications associatedwith the datagram protocol packets flowing in the network and virtualcircuits between each of the applications (step 502); determiningenforcement policies for each application that communicates with otherapplications over a datagram protocol (step 503); and providing theenforcement policies to the plurality of security agents for allowingand blocking communications associated with the datagram protocol (step504).

The telemetry can include metadata about the packet's headers, theapplication associated with socket, as packets transit a kernel'snetwork stack. The analyzing can include correlating and merging relatedtelemetry into a single event describing one or more datagram protocolpackets that flowed along a virtual circuit defined by a source InternetProtocol (IP) address, destination IP address, IP protocol number, andinformation required to uniquely identify a flow. The analyzing caninclude constructing a graph of all application software communicatingvia datagram protocols over the network.

The process 500 can include learning patterns of the applications todetermine which applications are capable of responding to unsoliciteddatagram messages (step 505). The process 500 can include dynamicallylimiting the telemetry collected and transmitted to for each datagramprotocol virtual circuit, based upon successfully matching telemetry fora corresponding virtual circuit (step 506). The process 500 can includereceiving a notification of kernel datagram protocol sockets beingopened and closed from the plurality of security agents (step 507).

CONCLUSION

It will be appreciated that some embodiments described herein mayinclude one or more generic or specialized processors (“one or moreprocessors”) such as microprocessors; Central Processing Units (CPUs);Digital Signal Processors (DSPs): customized processors such as NetworkProcessors (NPs) or Network Processing Units (NPUs), Graphics ProcessingUnits (GPUs), or the like; Field Programmable Gate Arrays (FPGAs); andthe like along with unique stored program instructions (including bothsoftware and firmware) for control thereof to implement, in conjunctionwith certain non-processor circuits, some, most, or all of the functionsof the methods and/or systems described herein. Alternatively, some orall functions may be implemented by a state machine that has no storedprogram instructions, or in one or more Application-Specific IntegratedCircuits (ASICs), in which each function or some combinations of certainof the functions are implemented as custom logic or circuitry. Ofcourse, a combination of the aforementioned approaches may be used. Forsome of the embodiments described herein, a corresponding device inhardware and optionally with software, firmware, and a combinationthereof can be referred to as “circuitry configured or adapted to,”“logic configured or adapted to,” etc. perform a set of operations,steps, methods, processes, algorithms, functions, techniques, etc. ondigital and/or analog signals as described herein for the variousembodiments.

Moreover, some embodiments may include a non-transitorycomputer-readable storage medium having computer-readable code storedthereon for programming a computer, server, appliance, device,processor, circuit, etc. each of which may include a processor toperform functions as described and claimed herein. Examples of suchcomputer-readable storage mediums include, but are not limited to, ahard disk, an optical storage device, a magnetic storage device, aRead-Only Memory (ROM), a Programmable Read-Only Memory (PROM), anErasable Programmable Read-Only Memory (EPROM), an Electrically ErasableProgrammable Read-Only Memory (EEPROM), Flash memory, and the like. Whenstored in the non-transitory computer-readable medium, software caninclude instructions executable by a processor or device (e.g., any typeof programmable circuitry or logic) that, in response to such execution,cause a processor or the device to perform a set of operations, steps,methods, processes, algorithms, functions, techniques, etc. as describedherein for the various embodiments.

Although the present disclosure has been illustrated and describedherein with reference to preferred embodiments and specific examplesthereof, it will be readily apparent to those of ordinary skill in theart that other embodiments and examples may perform similar functionsand/or achieve like results. All such equivalent embodiments andexamples are within the spirit and scope of the present disclosure, arecontemplated thereby, and are intended to be covered by the followingclaims. Moreover, it is noted that the various elements, operations,steps, methods, processes, algorithms, functions, techniques, etc.described herein can be used in any and all combinations with eachother.

What is claimed is:
 1. A non-transitory computer-readable storage mediumhaving computer-readable code stored thereon for programming a system toperform steps of: obtaining telemetry from a plurality of securityagents each operating on a device in a network, wherein the telemetry iscollected locally related to datagram protocol packets; analyzing thetelemetry to determine applications associated with the datagramprotocol packets flowing in the network and virtual circuits betweeneach of the applications; dynamically limiting the telemetry collectedand transmitted to for each datagram protocol virtual circuit, basedupon a probability of successfully matching telemetry for acorresponding virtual circuit; determining enforcement policies for eachapplication that communicates with other applications over a datagramprotocol; and providing the enforcement policies to the plurality ofsecurity agents based on the determining for allowing and blockingcommunications associated with the datagram protocol.
 2. Thenon-transitory computer-readable storage medium of claim 1, wherein thetelemetry includes metadata about the packet's headers, the applicationassociated with socket, as packets transit a kernel's network stack. 3.The non-transitory computer-readable storage medium of claim 1, whereinthe analyzing includes correlating and merging related telemetry into asingle event describing one or more datagram protocol packets thatflowed along a virtual circuit defined by a source Internet Protocol(IP) address, destination IP address, IP protocol number, andinformation required to uniquely identify a flow.
 4. The non-transitorycomputer-readable storage medium of claim 1, wherein the analyzingincludes constructing a graph of all application software communicatingvia datagram protocols over the network.
 5. The non-transitorycomputer-readable storage medium of claim 1, wherein the steps includelearning patterns of the applications to determine which applicationsare capable of responding to unsolicited datagram messages.
 6. Thenon-transitory computer-readable storage medium of claim 1, wherein thesteps include receiving a notification of kernel datagram protocolsockets being opened and closed from the plurality of security agents.7. A method comprising the steps of: obtaining telemetry from aplurality of security agents each operating on a device in a network,wherein the telemetry is collected locally related to datagram protocolpackets; analyzing the telemetry to determine applications associatedwith the datagram protocol packets flowing in the network and virtualcircuits between each of the applications; dynamically limiting thetelemetry collected and transmitted to for each datagram protocolvirtual circuit, based upon successfully matching telemetry for acorresponding virtual circuit; determining and developing policies foreach application that communicates with other applications over adatagram protocol; and providing the enforcement policies to theplurality of security agents on the determining for allowing andblocking communications associated with the datagram protocol.
 8. Themethod of claim 7, wherein the telemetry includes metadata about thepacket's headers, the application associated with socket, as packetstransit a kernel's network stack.
 9. The method of claim 7, wherein theanalyzing includes correlating and merging related telemetry into asingle event describing one or more datagram protocol packets thatflowed along a virtual circuit defined by a source Internet Protocol(IP) address, destination IP address, IP protocol number, andinformation required to uniquely identify a flow.
 10. The method ofclaim 7, wherein the analyzing includes constructing a graph of allapplication software communicating via datagram protocols over thenetwork.
 11. The method of claim 7, wherein the steps include learningpatterns of the applications to determine which applications are capableof responding to unsolicited datagram messages.
 12. The method of claim7, wherein the steps include receiving a notification of kernel datagramprotocol sockets being opened and closed from the plurality of securityagents.
 13. A server comprising: one or more processors and memorycomprising instructions that, when executed, cause the one or moreprocessors to obtain telemetry from a plurality of security agents eachoperating on a device in a network, wherein the telemetry is collectedlocally related to datagram protocol packets, analyze the telemetry todetermine applications associated with the datagram protocol packetsflowing in the network and virtual circuits between each of theapplications, dynamically limit the telemetry collected and transmittedto for each datagram protocol virtual circuit, based upon a probabilityof successfully matching telemetry for a corresponding virtual circuit,determine and develop policies for each application that communicateswith other applications over a datagram protocol; and provide thepolicies to the plurality of security agents based on the determiningfor allowing and blocking communications associated with the datagramprotocol.
 14. The server of claim 13, wherein the telemetry includesmetadata about the packet's headers, the application associated withsocket, as packets transit a kernel's network stack.
 15. The server ofclaim 13, wherein the analyzing includes correlating and merging relatedtelemetry into a single event describing one or more datagram protocolpackets that flowed along a virtual circuit defined by a source InternetProtocol (IP) address, destination IP address, IP protocol number, andinformation required to uniquely identify a flow.
 16. The server ofclaim 13, wherein the analyzing includes constructing a graph of allapplication software communicating via datagram protocols over thenetwork.
 17. The server of claim 13, wherein the instructions that, whenexecuted, cause the one or more processors to learn patterns of theapplications to determine which applications are capable of respondingto unsolicited datagram messages.